-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maintable leaves the Swing year and comes back in a new JavaFX dress #3591
Conversation
Cool! Could you point me to new implementation? In your large commit I see only a lot of Icon changes |
Oh, sorry - I forgot to commit all files. The main changes are in the |
While you are working on this, you might also take a look at #3356 |
Yes, this issue is already fixed merely by switching to JavaFX - the unicode is correctly displayed (see above the second entry in the table, the first screenshot shows the boxes while the correct string is shown in the second screenshot). |
|
||
import org.fxmisc.easybind.EasyBind; | ||
|
||
class ColumnFactory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not that happy with this generic name here... as this shadows the javafx classes
Maybe MaintableColumnFactory? Same as with the other CellFactory
} | ||
|
||
// Add columns for other file types | ||
for (String column : preferences.getExtraFileColumns()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe also addAll possible?=
|
||
Optional<String> content = Optional.empty(); | ||
for (String field : bibtexFields) { | ||
content = entry.getResolvedFieldOrAlias(field, database.orElse(null)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe stream with firstOrNull? or anyMatch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not possible because isNameColumn
has to be set.
List<String> fields = tabList.getTabFields(i); | ||
for (String field : fields) { | ||
for (Map.Entry<String, List<String>> tab : Globals.prefs.getEntryEditorTabList().entrySet()) { | ||
for (String field : tab.getValue()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tab.stream.anymatch( entry -> entry.getKey.equals(FieldName.File)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure that this is more readable, especially since the if statement still has to be there.
One more step in the right direction. This PR has the potential to fix a lot of display bugs and we should be able to get rid of the annoying and unmaintained glazed lists library. Nevertheless, I need to add a word of caution: We cannot allow the same situation as for the entry editor again. We've spent almost half a year in un-releaseable limbo because of that. The replacement for the main table needs to be absolutely bullet proof. However, the amount of lines of code in this PR is too much for a meaningful review, so we need A LOT of manual testing by basically all developers. I've played around a bit and I like the new layout of the maintable. What's a little strange is that every second row is highlighted differently. This should change for the final version. EDIT: Things that should be fixed with this PR ;) https://github.com/JabRef/jabref/issues?q=is%3Aissue+is%3Aopen+label%3Amaintable |
@Siedlerchr Thanks for the feedback. I'll improve the code accordingly. @lenhard I completely agree! We should find a way to have a realeasable version while still work on the migration to JavaFX. The main problem is that the code is tightly coupled to the maintable (i.e. there is no abstraction layer before the BasePanel/MainTable that used in the other Swing dialogs). This has the potential upset that every single dialog may now trigger a bug (for example because it runs some code not on the JavaFX thread). So, even through I will try to thoroughly test the new code before marking it as "ready-for-review", there might still be countless bugs left which we need to find (and fix) in teamwork. Moreover, for the same reason, I think we also need to release a beta again. That being said, the immediate question is: how much functionality should I try to migrate in this PR and what should follow as new PRs? As you said, the size of the changes makes the PR already unreviewable. But I would really like to have your feedback about some design questions. Especially since our aim should be not just to improve the gui but also decouple the code and make it more reusable. Currently the new maintable is in a state where the very basic functionality works and the code is decoupled enough to actually write unit gui tests for it. There are still some bugs/feature that definitely need to be fixed before a users touches it (e.g. restore column width, context menus for the icons, a few display bugs). Then there are a few features that are not essential and rather isolated (e.g. "marking of entries"). These are probably good candidates for follow-up PRs. And finally there are features that I don't really see any benefit in reimplementing (e.g. coloring of table cells when the field is optional/required) or that are not really possible to implement with JavaFX (e.g. "float search"). Finally, the possible bug fixes @lenhard mentions should also follow as new PRs. Any thoughts on this? (Sorry for the long text). |
I think we could have a separate main Table Beta Test-Release in an additional branch highly experimental and let some users test this functionality who are interested. Especially we would need some Mac/Linux guys |
We can create a The master branch must be release-ready at all times. Release-ready means: all features of the old versions should be working (or the dev team decided to remove/disable a feature, such as the auto completion). |
So, I used this version now in production during the past few days and fixed a lot of bugs. Although not all features are yet migrated (see list above), I mark this PR now as ready for review. All further changes are coming as extra PRs onto this branch. I would suggest that you try this version out and if nothing serious pops up, I would create a post in the forum advertising this PR and ask users about their opinion (something like a very early access program instead of several beta releases). What do you think? |
I would be really cool if you could provide a table that lists all features related to the maintable that were present in the Swing version, e.g. sorting options, right click options, entry drop, column sorting, and could indicate if these features are working in the new version. Then we would have an overview of what features actually exist in the main table and we could have a meaningful discussion about which features we want to drop. Personally, I don't really have an overview of all the things that the maintable can do. Could you perhaps provide this overview? I guess also @koppor know a thousand maintable features that I do not know. |
I changed the base branch to "maintable-beta". I would propose to proceed as follows:
Why?
In case we need a overview-pr, we can create a PR from |
I am very used to the floating search. See screenshots at #3618. |
@lenhard I updated the first post to also include the features that are already migrated (it is only the very basic functionality). Right now we do not need to decide what features should be dropped since there is still a lot fundamental functionality to migrate (but we should speak about it in the next devcall). I just don't want this PR to explode even more and get feedback about some of the other refactorings / changes. Thus the early ready-for-review. @koppor Sounds like a good plan. |
* upstream/master: (40 commits) CleanupStep.MOVE_PDF is not a CleanupPreset anymore Add link and fix casing Explicitly set jacoco version (#3617) Update gradle from 4.4 to 4.4.1 Update bcprov-jdk15on from 1.58 -> 1.59 Fix NPE when changing entries between databases Add exporter desc to enum analog to import (#3606) Create 0001-use-crowdin-for-translations.md [ci skip] Get more Open Source Helpers (#3601) Update dependencies (#3602) Lookup filetypes in enum set to prevent NPE due to uninitialized expo… (#3597) Make it possible to disable autocompletion in the search bar (#3600) New translations JabRef_en.properties (Chinese Simplified) New translations JabRef_en.properties (French) New translations JabRef_en.properties (German) New translations JabRef_en.properties (Indonesian) New translations JabRef_en.properties (Italian) New translations JabRef_en.properties (Japanese) New translations JabRef_en.properties (Russian) New translations JabRef_en.properties (Spanish) ...
…or and it is not used anylonger
I fixed the Close Entry Editor with Escape bug |
…avafxTable * 'javafxTable' of https://github.com/JabRef/jabref: Update CHANGELOG.md
@lenhard @Siedlerchr Is this architecturally OK? Then, I would propose to merge it into Note: The "real" PR of getting this into JabRef is #3621 - there, code updates are only made as PRs to that branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@koppor That's very hard to tell with a PR that big. It would be extremely helpful if the travis build was working for the PR, then the tests would report obvious violations.
I've had a look at the model and logic classes and could not spot a direct violation. There is one suggestion in a TODO, though. Maybe this is fixable? Otherwise the PR could move on imho.
@@ -8,7 +8,8 @@ | |||
*/ | |||
public class BibtexSingleField { | |||
|
|||
public static final int DEFAULT_FIELD_LENGTH = 100; | |||
// TODO: This constant should be moved to the gui package, probably to MainTableColumnFactory | |||
public static final double DEFAULT_FIELD_LENGTH = 100; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to move this as suggested in the comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not possible at the moment since the field is still used in other places in model. The new main table is free from this dependency but the import and search dialog still rely on it as the have before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, no problem. Then just leave as it is.
* First prototype * Make old actions list an enum * Make it work! * Implement feedback
* Show special field icons properly in main table * Make icons functional * Fix NPE * Handle file icon click
2017:
2018:
There are still many many things missing for a fully working version but I thought I give you an early preview. Feedback welcome.
Happy new year everybody!
Fixes #3356, fixes #3532 and fixes #3112.
Known bugs: (ticked = resolved)
Status of features:
gradle localizationUpdate
?